QLNX Linux RAT targets developers to steal credentials and enable supply chain attacks

A newly documented Linux malware family called Quasar Linux, or QLNX, is targeting developers and DevOps environments with credential theft, rootkit features, and long-term remote access. Trend Micro says the malware is built to steal the secrets that connect developer machines to package registries, source code platforms, cloud environments, and CI/CD pipelines.

The threat is serious because developer credentials can unlock far more than one Linux workstation. Stolen npm tokens, PyPI credentials, Git tokens, SSH keys, Docker credentials, Kubernetes configs, and AWS secrets can give attackers a path into software supply chains and cloud infrastructure.

QLNX also uses stealth and persistence techniques that make removal difficult. It can run in memory, delete its original binary from disk, hide behind fake kernel-style process names, deploy a PAM backdoor, and use rootkit components to conceal files, processes, and ports.

Why QLNX is a supply chain threat

Developers and DevOps engineers often hold credentials that can publish packages, update containers, access repositories, manage infrastructure, and deploy production code. That makes their workstations high-value targets.

Trend Micro said QLNX searches for credentials and configuration files linked to npm, PyPI, Git, AWS, Kubernetes, Docker, Vault, Terraform, GitHub CLI, SSH, and .env files. If attackers steal those secrets, they may be able to push malicious code through trusted developer accounts.

This creates a larger blast radius than a normal endpoint infection. One compromised maintainer account can lead to poisoned packages, backdoored build artifacts, cloud access, or lateral movement into CI/CD systems.

At a glance

Detail	What researchers found
Malware name	Quasar Linux, or QLNX
Platform	Linux
Primary targets	Developers, DevOps systems, and Linux build environments
Main risk	Credential theft that can enable supply chain compromise
Key components	Remote access trojan, LD_PRELOAD rootkit, eBPF rootkit controller, PAM backdoor, keylogger, and credential harvester
Persistence methods	LD_PRELOAD, systemd, crontab, init.d, .bashrc, and XDG autostart
Notable capability	Peer-to-peer mesh networking that can relay commands through other infected machines

How QLNX hides on Linux systems

QLNX is designed for stealth from the start. Trend Micro said the implant can run in memory, delete the original binary from disk, and spoof process names to look like normal Linux kernel threads.

The malware carries embedded C source code for its rootkit and PAM backdoor. It compiles those components on the victim machine with gcc, then deploys them through /etc/ld.so.preload for system-wide interception.

This approach helps QLNX blend into the host and avoid simple file-based detection. It also gives attackers control over what standard tools can see.

The PAM backdoor captures passwords

PAM, or Pluggable Authentication Module, handles authentication on many Linux systems. QLNX abuses this layer by deploying a malicious PAM component that can intercept credentials during login.

Trend Micro said the malware can harvest plaintext credentials from authentication events and store captured data in hidden log files such as /var/log/.ICE-unix. It also includes a hardcoded master password that can act as a backdoor.

This is especially dangerous on developer machines and servers because one captured password can open SSH access, sudo paths, internal repositories, cloud consoles, or build infrastructure.

What QLNX tries to steal

• SSH private keys and known host data
• npm authentication tokens from .npmrc files
• PyPI credentials from .pypirc files
• Git credentials and repository configuration
• AWS credentials and cloud configuration files
• Kubernetes tokens and kubeconfig files
• Docker Hub credentials from docker configuration files
• Vault tokens and Terraform credentials
• GitHub CLI tokens
• .env files that may contain API keys and secrets
• Browser profiles and other locally stored credentials

Rootkit features make detection harder

QLNX uses a two-layer hiding strategy. The first layer uses LD_PRELOAD to hook user-space functions and hide selected activity from normal Linux tools.

The second layer uses an eBPF rootkit controller. Trend Micro said this component manages BPF maps that can help conceal processes, files, and network ports from standard userland tools.

As a result, commands such as ps, top, netstat, and directory listings may not show the full picture on an infected machine. Security teams need telemetry that can detect tampering and compare user-space output against lower-level signals.

Remote access features expand the damage

QLNX is not only a stealer. Trend Micro said the implant supports dozens of command handlers for remote shell access, file management, process control, uploads, downloads, screenshots, keylogging, TCP sockets, credential theft, and SSH-based remote command execution.

The malware also includes peer-to-peer mesh networking. Infected systems can relay commands through each other, which can make takedown and eradication harder if multiple machines in an environment are compromised.

This gives attackers options after the first infection. They can steal secrets, move laterally, maintain access, and use one developer machine as a stepping stone into other systems.

What security teams should check now

• Inspect /etc/ld.so.preload for unexpected entries.
• Search for /usr/lib/libsecurity_utils.so.1 and /usr/lib/.libpam_cache.so.
• Look for hidden credential logs such as /var/log/.ICE-unix and /var/log/.Test-unix.
• Review /tmp for suspicious lock files such as /tmp/.X752e2ca1-lock.
• Audit systemd, crontab, init.d, .bashrc, and XDG autostart entries.
• Hunt for gcc compilation activity that creates shared objects in unusual paths.
• Compare process listings with lower-level telemetry to identify hidden processes.
• Review developer endpoints for unusual SSH, Git, npm, PyPI, Docker, AWS, and Kubernetes activity.
• Rotate developer tokens and cloud secrets after any suspected infection.

How organizations can reduce risk

Developer machines should not hold long-lived secrets when shorter-lived identity and access methods can work. Teams should move toward scoped tokens, short expiration windows, hardware-backed MFA, and least-privilege access for package publishing and cloud operations.

Build systems also need separation. A developer laptop should not have unrestricted access to production infrastructure, package publishing workflows, and CI/CD secrets at the same time.

Organizations should monitor Linux endpoints with the same urgency they apply to Windows workstations. QLNX shows that Linux developer systems can become the first step in a broader software supply chain intrusion.

FAQ