A previously undocumented Linux implant known as Quasar Linux RAT, or QLNX, has been observed targeting developer and DevOps environments. The malware is designed to establish a silent foothold on Linux systems and give attackers extensive post-compromise capabilities, including credential theft, keylogging, file manipulation, clipboard monitoring, network tunneling, and long-term stealth.
According to Trend Micro researchers Aliakbar Zahravi and Ahmed Mohamed Ibrahim, QLNX is especially dangerous because it focuses on the software supply chain. Instead of only targeting standard user accounts, it goes after the credentials developers use to publish code, access cloud platforms, manage containers, and operate CI/CD environments.
Why Developers Are the Main Target
Developer machines often contain highly valuable secrets. These systems may have access to source code repositories, cloud environments, package registries, Kubernetes clusters, Docker registries, infrastructure-as-code tools, and internal deployment pipelines.
QLNX is built to search for and extract secrets from files commonly found in developer environments, including:
.npmrcfor npm tokens.pypircfor PyPI credentials.git-credentials.aws/credentials.kube/config.docker/config.json.vault-token- Terraform credentials
- GitHub CLI tokens
.envfiles
If attackers gain access to these credentials, they may be able to publish malicious packages, compromise cloud infrastructure, modify application code, or pivot deeper into CI/CD pipelines.
This makes QLNX more than just a Linux remote access trojan. It is a direct threat to the software supply chain.
Supply Chain Risk: One Compromised Developer Can Impact Many
The biggest concern is the downstream impact.
If a package maintainer, DevOps engineer, or developer account is compromised, attackers could potentially push poisoned versions of legitimate software packages to npm, PyPI, or other registries. These malicious updates may then be automatically downloaded by other developers, build systems, and production environments.
This type of attack can spread quickly because many organizations trust dependencies, package maintainers, and automated deployment workflows.
A single compromised workstation can therefore become the starting point for a much larger supply chain incident.
How QLNX Stays Hidden
QLNX is designed for long-term stealth. It executes filelessly from memory and can disguise itself as a legitimate-looking Linux kernel thread, using names such as kworker or ksoftirqd.
The malware also profiles the host to detect whether it is running inside a containerized environment. This helps it adapt its behavior and avoid detection.
To maintain persistence, QLNX uses multiple redundant methods, including:
- systemd services
- crontab entries
.bashrcshell injection- additional persistence mechanisms designed to survive reboots and cleanup attempts
It can also wipe system logs to hide evidence of compromise.
Rootkit Capabilities: Hiding in Userspace and Kernel Space
One of the most concerning parts of QLNX is its two-tier rootkit architecture.
First, it uses a userland rootkit through the Linux dynamic linker’s LD_PRELOAD mechanism. This allows the malware to hide files, processes, and other artifacts from common userland tools.
Second, it includes a kernel-level eBPF component. By abusing the Linux BPF subsystem, QLNX can hide processes, files, and network ports from standard tools such as:
pslsnetstat
This combination makes detection much harder, especially if defenders rely only on traditional command-line inspection tools.
Credential Theft Through PAM Backdoors
QLNX also includes Pluggable Authentication Module, or PAM, backdoor functionality.
This allows it to intercept plaintext credentials during authentication events. It can also log outbound SSH session data and transmit the stolen information to attacker-controlled infrastructure.
The malware supports a second PAM-based credential logger that can be automatically loaded into dynamically linked processes. This allows it to extract service names, usernames, and authentication tokens.
For organizations using Linux servers, DevOps jump boxes, or developer workstations, this is a serious risk because authentication activity itself becomes a source of credential theft.
Command-and-Control and Remote Control Features
Once QLNX gains a foothold, it enters a persistent operational loop. It continuously attempts to communicate with attacker-controlled command-and-control servers using raw TCP, HTTPS, and HTTP.
The malware reportedly supports 58 distinct commands, giving operators broad control over the compromised host.
Its capabilities include:
- executing shell commands
- managing files
- injecting code into processes
- taking screenshots
- logging keystrokes
- monitoring clipboard activity
- establishing SOCKS proxies
- creating TCP tunnels
- running Beacon Object Files
- managing a peer-to-peer mesh network
This gives attackers both espionage and lateral movement capabilities.
Why QLNX Is Particularly Dangerous
QLNX is dangerous not because of one single feature, but because of how all of its capabilities work together.
It can arrive silently, erase traces from disk, establish multiple persistence methods, hide at both the userspace and kernel level, steal high-value credentials, and then use those credentials to move deeper into development and cloud environments.
For DevOps and software engineering teams, this creates a high-impact risk: the compromise of one Linux workstation may lead to broader compromise of code repositories, cloud platforms, container registries, and production pipelines.
Defensive Recommendations
Organizations should treat developer machines and CI/CD systems as high-value assets, not as standard endpoints.
Recommended actions include:
- rotate exposed developer and DevOps credentials immediately after suspected compromise
- monitor access to npm, PyPI, GitHub, Docker, Kubernetes, Vault, AWS, Azure, and GCP accounts
- avoid storing long-lived secrets in local configuration files
- use short-lived tokens and identity-based access where possible
- enforce MFA for source control, cloud platforms, and package registries
- monitor suspicious changes to
.bashrc, crontab, systemd services, PAM modules, andLD_PRELOAD - use EDR or runtime security tools capable of detecting memory-resident malware and eBPF abuse
- regularly audit CI/CD pipeline permissions
- separate developer, admin, and production access
- review package publishing activity for unexpected releases
Security teams should also validate detections using trusted forensic tooling, not only standard Linux utilities, because rootkit functionality may hide malicious activity from normal commands.
Final Thoughts
QLNX highlights a growing trend in modern cyberattacks: developers and DevOps engineers are becoming primary targets.
As organizations rely more heavily on cloud platforms, open-source packages, containers, and automated deployment pipelines, developer credentials have become extremely valuable. Malware like QLNX is built specifically to exploit that reality.
Protecting the software supply chain now requires more than securing production servers. It requires strong security controls across developer workstations, CI/CD systems, package publishing workflows, and cloud access paths.
