Trend Micro researchers have described a previously undocumented Linux implant codenamed Quasar Linux RAT (QLNX), which, according to their findings, targets systems used by developers and DevOps engineers with the goal of stealing credentials that provide access to package registries, cloud infrastructure, and CI/CD pipelines. The malware is reported to execute filelessly from memory, use a two-tier rootkit architecture, and support 58 different commands that give the operator full control over the compromised host. The threat affects Linux systems used in software development and operations processes.
Targeted collection of developer secrets
The key feature of QLNX that sets it apart from other Linux remote access Trojans is a specialized credential collection module focused specifically on the development ecosystem. According to researchers Aliakbar Zahravi and Ahmed Mohamed Ibrahim, the module extracts secrets from the following files and configurations:
- .npmrc — NPM tokens
- .pypirc — PyPI credentials
- .git-credentials — Git repository access data
- .aws/credentials — AWS access keys
- .kube/config — Kubernetes configuration
- .docker/config.json — Docker credentials
- .vault-token — HashiCorp Vault tokens
- Terraform credentials, GitHub CLI tokens, and .env files
Compromise of these assets, in Trend Micro’s assessment, can potentially allow an attacker to publish malicious packages to NPM or PyPI registries, gain access to cloud infrastructure, or pivot through CI/CD pipelines. This creates a risk of cascading attacks against the software supply chain: a single compromised package maintainer can become an entry point for large-scale distribution of malicious code.
Stealth and persistence mechanisms
QLNX reportedly demonstrates an advanced set of techniques for evading detection. The implant runs filelessly from RAM and masquerades as legitimate kernel threads — for example, kworker or ksoftirqd — which makes it difficult to spot using standard process monitoring tools.
For persistence in the system, at least seven different methods are believed to be used, including:
- systemd units
- crontab jobs
- Injections into .bashrc
The implant also profiles the host to detect containerized environments and wipes system logs to conceal traces of its activity.
Two-tier rootkit architecture
The two-tier hiding architecture is particularly noteworthy. In user space, QLNX reportedly uses the Linux dynamic linker’s LD_PRELOAD mechanism to hook system calls and hide the implant’s artifacts and processes. At the kernel level, it leverages an eBPF-based component that, on command from the control server, hides processes, files, and network ports from standard utilities such as ps, ls, and netstat.
The combination of user-space and kernel-space rootkits significantly complicates detection: even if one layer of concealment is neutralized, the other continues to mask the implant’s presence.
Intercepting authentication via PAM
QLNX is reported to include a backdoor based on the Pluggable Authentication Module (PAM) framework, which intercepts plaintext credentials during authentication events, logs data from outbound SSH sessions, and transmits the collected information to the control server. In addition, a second PAM-based credential collection module is described, which is automatically loaded into every dynamically linked process to extract the service name, username, and authentication token.
Command-and-control infrastructure and capabilities
After establishing persistence, the implant enters its main operational phase, continuously attempting to establish and maintain communication with the C2 server over raw TCP, HTTPS, and HTTP protocols. According to the researchers, the set of 58 supported commands includes:
- Execution of arbitrary shell commands
- File operations and code injection into processes
- Screen capture and keystroke logging
- Setting up SOCKS proxies and TCP tunnels
- Execution of Beacon Object Files (BOF)
- Managing a peer-to-peer (P2P) mesh network
The exact initial delivery mechanism for QLNX remained unknown at the time the research was published.
Impact assessment
The highest risk is faced by organizations where developers work on Linux systems and store infrastructure access secrets on them — such as package registry tokens, cloud provider keys, and container orchestration configurations. Compromise of a single developer workstation can lead to publication of poisoned packages, unauthorized access to production cloud infrastructure, and lateral movement through CI/CD pipelines.
Important caveat: at the time of publication, no indicators of compromise (hashes, IP addresses, domains), confirmed cases of real-world attacks, or package poisoning incidents had been provided. The assessment of the threat’s scale is based on analysis of the implant’s capabilities rather than documented incidents.
Security recommendations
- Audit secret storage: ensure that NPM, PyPI, AWS, Docker, Kubernetes, and other secrets are not stored in plaintext in home directories. Use secret managers and short-lived tokens.
- Monitor LD_PRELOAD: check the LD_PRELOAD environment variable and the /etc/ld.so.preload file for unexpected entries.
- Control eBPF programs: use bpftool to inventory loaded BPF programs and identify anomalous modules.
- Inspect PAM configuration: regularly review files in /etc/pam.d/ and loaded PAM modules for unauthorized changes.
- Monitor process masquerading: pay attention to processes named kworker or ksoftirqd that do not match expected kernel threads.
- Check persistence mechanisms: audit systemd units, crontab jobs, and .bashrc files for suspicious entries.
- Rotate secrets: if compromise is suspected, immediately rotate all tokens and access keys stored on the affected system.
The described QLNX implant illustrates a trend toward malware specifically targeting development infrastructure. The top-priority action for security teams is to inventory secrets stored in plaintext on developer workstations and migrate them to centralized secret stores that support short-lived tokens and access auditing.