Quasar Linux RAT Steals Developer Credentials for Software Supply Chain Compromise

Security researchers at Trend Micro have identified a previously undocumented Linux remote access trojan (RAT) codenamed Quasar Linux RAT, or QLNX, that is actively targeting developers and DevOps professionals to facilitate software supply chain compromise. The malware is designed to establish silent, long-term footholds on compromised systems, harvesting credentials for package registries, cloud infrastructure, and CI/CD pipelines before exfiltrating data to attacker-controlled servers.

How QLNX targets developer credentials

Trend Micro researchers Aliakbar Zahravi and Ahmed Mohamed Ibrahim detailed the malware's capabilities in a recent technical analysis, noting that QLNX prioritizes stealing secrets from files commonly found in developer environments. These include .npmrc files containing npm tokens, .pypirc files with PyPI credentials, .git-credentials storing Git login details, .aws/credentials for AWS access, .kube/config for Kubernetes clusters, .docker/config.json with Docker Hub credentials, HashiCorp .vault-token files, Terraform credentials, GitHub CLI tokens, and plaintext .env files used to store environment variables.

Compromising these assets gives attackers a wide range of options for further exploitation. Stolen npm or PyPI tokens allow bad actors to push malicious packages to public registries, which are then downloaded by millions of downstream users, creating a cascading supply chain attack. Cloud credentials grant access to enterprise infrastructure, while CI/CD pipeline secrets let attackers modify build processes to inject malicious code into software before it is shipped to customers.

Stealth and persistence mechanisms

QLNX is built for stealth and persistence. It executes filelessly from memory, meaning no malicious binaries are written to the disk, and masquerades as legitimate kernel threads such as kworker or ksoftirqd to evade process monitoring tools. Once a foothold is established, the malware attempts to maintain communication with its command-and-control (C2) server over raw TCP, HTTPS, or HTTP, entering a persistent loop to receive instructions.

The malware uses seven distinct methods to maintain access to compromised systems, including systemd service entries, crontab scheduled tasks, and .bashrc shell injection. It also wipes system logs to remove traces of its activity, making post-incident forensics more difficult.

QLNX uses a two-tiered rootkit design to stay hidden. The userland component leverages the Linux dynamic linker's LD_PRELOAD mechanism to intercept system calls and hide the malware's processes, files, and network activity from standard tools like ps, ls, and netstat. The kernel-level component uses extended Berkeley Packet Filter (eBPF) programs to conceal artifacts at the kernel level, only activating when instructed by the C2 server. This dual-layer hiding makes QLNX extremely difficult to detect with traditional security tools.

The malware also includes two Pluggable Authentication Module (PAM) backdoors. The first is an inline hook that intercepts plaintext credentials during authentication events, logs outbound SSH session data, and transmits this information to the C2 server. The second is a credentials logger that loads into every dynamically linked process to extract service names, usernames, and authentication tokens.

C2 capabilities and attack workflow

QLNX supports 58 distinct commands, giving operators near-complete control of compromised hosts. These commands allow attackers to execute shell commands, manage files, inject code into running processes, take screenshots, log keystrokes, establish SOCKS proxies and TCP tunnels, run Beacon Object Files (BOFs), and even manage a peer-to-peer (P2P) mesh network to route traffic between infected systems.

Trend Micro researchers emphasized that QLNX's danger comes from how its features chain together, rather than any single capability. "The QLNX implant was built for long-term stealth and credential theft," the researchers wrote. "What makes it particularly dangerous is not any single feature, but how its capabilities chain together into a coherent attack workflow: arrive, erase from disk, persist through six redundant mechanisms, hide at both userspace and kernel level, and then harvest the credentials that matter most."

It is currently unclear how QLNX is initially delivered to target systems. Trend Micro did not disclose specific infection vectors, but common delivery methods for Linux RATs targeting developers include phishing emails with malicious attachments, compromised Docker images, malicious VS Code extensions, or poisoned dependencies in public package registries.

Practical steps to defend against QLNX

For developers and DevOps teams, the discovery of QLNX highlights the need for stricter supply chain and credential hygiene. Below are actionable steps to reduce risk:

1. Replace plaintext credential files with secret managers: Avoid storing tokens, passwords, and API keys in plaintext files like .npmrc, .pypirc, or .env. Use dedicated secret management tools such as HashiCorp Vault, AWS Secrets Manager, or GitHub's encrypted secrets for CI/CD pipelines. These tools store credentials in encrypted formats and rotate them automatically, reducing the impact of a single file compromise.

2. Restrict LD_PRELOAD abuse: The LD_PRELOAD mechanism is a common vector for userland rootkits. Set the LD_PRELOAD environment variable to an empty string for all unprivileged users, and use Linux security modules like AppArmor or SELinux to prevent unauthorized processes from modifying dynamic linker behavior. You can also enable the no_new_privs bit for sensitive processes to limit privilege escalation.

3. Monitor for eBPF anomalies: QLNX's kernel-level hiding relies on eBPF programs, which are increasingly used by both legitimate tools and malware. Use eBPF-based security monitoring tools like Falco, Cilium, or Tracee to detect unauthorized eBPF program loading. Alert on any eBPF programs that are not signed by trusted vendors or that modify process, file, or network visibility.

4. Implement centralized, immutable logging: QLNX wipes local system logs to cover its tracks. Forward logs to a centralized security information and event management (SIEM) system or cloud-based logging service that the malware cannot access. Use log integrity monitoring to detect if local logs are modified or deleted.

5. Enforce multi-factor authentication (MFA) everywhere: Even if credentials are stolen, MFA can prevent attackers from using them. Enable MFA for all package registry accounts (npm, PyPI, GitHub), cloud infrastructure consoles, CI/CD pipelines, and SSH access. Use hardware security keys like YubiKeys for the highest level of protection.

6. Limit credential file permissions: Restrict access to sensitive credential files so only the necessary processes and users can read them. For example, set .aws/credentials to 600 permissions (read/write only for the owner) and ensure the owner is a service account rather than a human user where possible. Avoid storing credential files in shared directories or version control systems.

7. Scan for fileless malware: Traditional antivirus tools often miss fileless malware like QLNX that executes from memory. Use Linux-compatible endpoint detection and response (EDR) tools that monitor memory for malicious code injection, unusual process behavior, and C2 communication patterns. Regularly scan container images and CI/CD pipelines for known RAT signatures.

8. Verify package integrity: To mitigate the risk of poisoned packages, use package signing and attestations for all dependencies. For npm, enable npm audit and use provenance checks to verify that packages are published by trusted maintainers. For PyPI, use pip with hash checking or tools like Trivy to scan dependencies for known vulnerabilities or malicious code.

9. Network segmentation and monitoring: QLNX communicates with C2 servers over standard protocols like HTTPS. Segment developer environments from production infrastructure, and monitor network traffic for connections to unknown IP addresses or domains. Use TLS inspection if possible to detect malicious traffic hidden in encrypted HTTPS streams.

10. Regularly rotate credentials: Even if credentials are not known to be compromised, rotate them regularly. This limits the window of opportunity for attackers who may have stolen old credentials. Automate credential rotation for cloud access keys, registry tokens, and CI/CD secrets where possible.

Broader context for supply chain security

QLNX is part of a growing trend of malware targeting developer environments to launch supply chain attacks. Recent months have seen similar campaigns like the Checkmarx supply chain compromise, which hit Bitwarden CLI and Docker images, and the fast16 malware targeting engineering software disclosed earlier this week. As software supply chains become more complex, securing developer workstations and credential storage is no longer optional. It is a core requirement for preventing cascading attacks that affect millions of users.