Quasar Linux (QLNX): Rootkit and PAM Backdoor Targeting Developer Credentials

A previously undocumented Linux malware family named Quasar Linux (QLNX) is targeting software developers with a combination of a userland rootkit, a kernel-level stealth component, a PAM backdoor, and a 58-command remote access framework — while only four security solutions currently detect it. Trend Micro researchers published their analysis on May 4, 2026, disclosing a full-featured implant designed specifically to harvest the credentials that underpin modern software development and cloud infrastructure.

Quasar Linux QLNX: Technical Details

QLNX is a Linux RAT (Remote Access Trojan — malware that gives an attacker complete remote interactive control over the infected host) with an unusually deep set of evasion and persistence capabilities. Unlike generic Linux malware that relies on a single persistence mechanism or a simple reverse shell, QLNX combines multiple stealth layers and attack modules into a single implant.

Trend Micro's full research and BleepingComputer's coverage describe the following architecture:

Dual-Layer Rootkit

QLNX deploys a two-component rootkit (software that hides a malware infection from the operating system and security tools):

LD_PRELOAD Rootkit (userland): The malware dynamically compiles a malicious shared library on the target host using gcc (the system's own C compiler), then injects it into all dynamically linked processes via /etc/ld.so.preload. This means every process that launches after infection loads the attacker's code first — intercepting system calls, hiding malicious files and network connections, and hooking authentication functions.

eBPF Component (kernel level): eBPF (Extended Berkeley Packet Filter — a Linux kernel subsystem that allows running sandboxed programs in the kernel without modifying kernel source code) provides QLNX with visibility into kernel-level events. This component deepens the malware's ability to hide activity that userland rootkits would miss, such as network connections made by other processes.

PAM Backdoor

QLNX installs a backdoor into PAM (Pluggable Authentication Modules — the Linux framework that handles all authentication, including sudo, SSH logins, and local console access). The PAM backdoor intercepts authentication events in plaintext, capturing passwords at the moment they are typed — including passwords for privileged accounts. This is particularly dangerous in developer environments where sudo and SSH are used constantly.

58-Command Remote Access Framework

The core RAT component supports 58 distinct commands covering shell access, file read/write, process management, system reconnaissance, and implant self-management. Communication uses custom TCP/TLS or HTTPS channels to the attacker's C2 infrastructure. Additional modules provide:

• Keylogging — records all keystrokes system-wide
• Screenshot capture — grabs visual desktop state
• SOCKS proxy — tunnels attacker traffic through the infected host
• TCP tunneling — pivots into internal networks
• Process injection — hides malicious code inside legitimate processes

Credential Targeting

QLNX systematically targets the files that hold developer and DevOps credentials:

| File | Credential Type | |——|—————-| | .npmrc | NPM registry tokens (Node.js package publishing) | | .pypirc | PyPI upload keys (Python package publishing) | | .git-credentials | Git repository credentials | | .aws/credentials | AWS access key ID and secret | | .kube/config | Kubernetes cluster access tokens | | .docker/config.json | Docker registry credentials | | /etc/shadow | System password hashes for all accounts | | SSH private keys (~/.ssh/id_*) | Remote server access |

Exploitation Status and Threat Landscape

Trend Micro has not identified active exploitation campaigns or attributed QLNX to a specific threat actor. The malware was discovered in development and DevOps environments spanning npm, PyPI, GitHub, AWS, Docker, and Kubernetes ecosystems — suggesting it is deployed where developers work, though the initial infection vector has not been definitively established.

At time of publication, only four of 60+ security solutions in VirusTotal detect the QLNX binary as malicious. This near-zero detection rate, combined with in-memory execution (the malware runs in RAM and deletes its original binary from disk after deployment), means most endpoint detection and response (EDR) solutions relying on file signatures will not identify active infections.

The supply chain implications are significant. The March 2026 LiteLLM compromise followed an identical credential-theft pattern — stolen NPM or PyPI credentials from one developer's machine were used to trojanize a Python AI package with 3.4 million daily downloads. A developer's workstation compromised by QLNX represents not just a single infected machine, but a potential entry point into every package, repository, and cloud environment that developer can access.

QLNX is not related to the Windows-based Quasar RAT open-source remote access tool. The name similarity appears coincidental.

Who Is Affected

QLNX specifically targets Linux systems used in software development and DevOps operations. High-risk environments include:

• Developer workstations running Linux (Ubuntu, Debian, Fedora, Arch, etc.)
• CI/CD build servers (Jenkins, GitLab Runner, GitHub Actions self-hosted runners)
• Container orchestration nodes (Kubernetes worker nodes, Docker hosts)
• Cloud-connected engineering workstations with AWS, GCP, or Azure credentials stored locally

The malware's targeting of cloud configuration files means the blast radius of a single infected developer machine extends to every cloud resource that developer's credentials can reach — S3 buckets, EC2 instances, EKS clusters, container registries, and more.

What You Should Do Right Now

• Audit developer Linux systems for /etc/ld.so.preload — a non-empty file on a system where you did not deliberately configure LD_PRELOAD injection is a high-confidence indicator of rootkit deployment.
• Check for unauthorized PAM module files in /lib/security/ or /lib64/security/. Any unfamiliar .so file warrants immediate investigation.
• Examine crontab, systemd units, init.d scripts, XDG autostart, and .bashrc entries for unexpected executables or scripts — QLNX uses all seven of these for persistence.
• Rotate all developer credentials immediately if any development workstation shows rootkit indicators: AWS keys, Docker tokens, npm auth tokens, PyPI upload keys, Kubernetes service account tokens, and SSH private keys.
• Review cloud access logs for unusual API calls from developer credentials — look for ListBuckets, DescribeInstances, or IAM enumeration calls during off-hours.
• Deploy network-layer monitoring for outbound TLS connections to unknown hosts from CI/CD and developer systems, particularly during build jobs.

# Check for LD_PRELOAD rootkit indicator
cat /etc/ld.so.preload 2>/dev/null && echo "INVESTIGATE: ld.so.preload is not empty"

# List PAM modules for unexpected entries
ls -la /lib/security/ /lib64/security/ 2>/dev/null | grep -v "^total\|pam_"

Background: Understanding the Risk

Developer workstations are one of the highest-value targets in modern enterprise security. A single compromised developer machine with cloud credentials stored in ~/.aws/credentials or ~/.kube/config gives an attacker lateral movement into cloud infrastructure that may host production workloads, customer data, and internal services. Traditional endpoint security is designed primarily for Windows, and Linux-specific malware like QLNX receives far less detection coverage.

The PAM backdoor attack is particularly insidious because it operates at the authentication layer itself. Any password entered via sudo, SSH, or local login on a QLNX-infected system is captured in plaintext — meaning even strong passwords and password managers offer no protection once the PAM module is installed.

The LD_PRELOAD rootkit technique is well-established in Linux malware (used by families like Ebury, active for over a decade), but QLNX's combination of userland LD_PRELOAD with a kernel eBPF component represents a meaningful capability upgrade. The eBPF layer provides visibility into kernel events that userland hooks cannot intercept, making traditional LD_PRELOAD detection (checking /etc/ld.so.preload and comparing process memory maps) insufficient on its own.

Seven persistence mechanisms deployed in parallel means removing QLNX requires finding and cleaning all seven independently. Failure to remove even one allows the implant to reinstall itself on reboot or shell initialization. Rebuilding the compromised host from a known-clean image is safer than attempting manual removal.

Conclusion

QLNX represents a serious threat to any organization with Linux-based development or DevOps infrastructure. Near-zero detection rates and deep kernel integration mean passive defenses will not catch it — proactive hunting on developer systems, combined with immediate credential rotation on any confirmed infection, is the required response. Given QLNX's explicit targeting of cloud credential files, treat a confirmed QLNX infection the same way you would treat a cloud credential leak: assume full cloud access is compromised and investigate accordingly.