Deep Dive: Analyzing Quasar Linux (QLNX), the Stealthy Supply-Chain Trojan

A sophisticated new threat actor has emerged in the Linux ecosystem: Quasar Linux (QLNX).

Despite its name, this is not a port of the well-known Windows-based QuasarRAT; instead, it is a purpose-built, stealth-oriented Remote Access Trojan (RAT) engineered specifically to compromise developer workstations and DevOps environments. By targeting these high-privilege machines, attackers aim to establish beachheads for massive software supply-chain compromises.

QLNX has been observed infiltrating a variety of Linux distributions—including Debian, Ubuntu, RHEL, Fedora, and Arch—specifically targeting CI/CD build hosts and workstations. These environments are goldmines for attackers, providing direct access to source code repositories, automated build pipelines, package registries, and cloud orchestration tools.

The primary strategic objective of QLNX is the systematic exfiltration of high-value credentials. This includes SSH private keys, Git personal access tokens, NPM and PyPI credentials, AWS and Kubernetes configuration secrets, and sensitive project-level .env files. By capturing these assets, an attacker can move laterally from a single workstation into the heart of a company’s cloud infrastructure or inject malicious code directly into production software.

Advanced Fileless Execution and Evasion

QLNX is designed to bypass traditional file-based security scanners by transitioning almost immediately from a single ELF binary to a pure in-memory execution model. Upon execution, the malware leverages specialized Linux syscalls, such as memfd_create, to instantiate an anonymous in-memory file. It then writes its primary payload into this file descriptor and executes it via execveat. To finalize its disappearance, the original on-disk binary is unlinked, leaving the running process with no visible executable file on the filesystem.

To further camouflage itself from system administrators, QLNX performs process masquerading. It rewrites its own comm and argv fields to impersonate legitimate kernel worker threads, such as [kworker/0:0] or [migration/0]. This ensures that a casual glance at tools like ps or top reveals nothing out of the ordinary.

According to a technical analysis by Trend Micro and GuardSix, QLNX is a highly modular platform. It features 58 distinct command handlers that grant an attacker capabilities ranging from remote shell access and SOCKS proxying to advanced process management and rootkit control.

One of its most notable technical behaviors is its “on-the-fly” compilation. Rather than carrying a massive library of pre-compiled binaries that might trigger signature-based detection, QLNX embeds C source code and uses the host’s own gcc compiler to dynamically build its rootkit and PAM (Pluggable Authentication Module) components. These unique, per-host shared objects are often tucked away in transient directories like /dev/fd/ or /tmp/, making static detection nearly impossible.

A Two-Tiered Rootkit Architecture

QLNX employs a sophisticated, dual-layered approach to maintain persistence and hide its presence:

• User-Space Layer (LD_PRELOAD): The malware injects itself into the system via /etc/ld.so.preload using malicious libraries such as libsecurity_utils.so.1. This forces every dynamically linked process to load the malware, allowing it to intercept system calls and hide files, network connections, and processes from standard user-space utilities.
• Kernel-Space Layer (eBPF): To provide deeper stealth, QLNX utilizes eBPF (Extended Berkeley Packet Filter). By utilizing BPF maps and programs, the malware can conceal specific Process IDs (PIDs), file paths, and network ports directly at the kernel level, effectively blinding defenders who rely on standard monitoring tools.

Furthermore, QLNX compromises the authentication process by deploying malicious PAM modules (e.g., pam_security.so). These modules integrate into the existing PAM stack to log cleartext passwords during local logins and sudo escalations. These harvested credentials, along with SSH keys and cloud tokens, are stored in XOR-encrypted hidden files located in non-standard paths like /var/log/.ICE-unix or /tmp/.pam_cache.

Figure 1: Rootkit injection workflow (Source: GuardSix).

Communication is handled through a decentralized Peer-to-Peer (P2P) mesh. Rather than communicating with a single, easily blockable Command and Control (C2) IP, compromised hosts act as relays for one another. While the protocol uses a specific “magic value” for handshaking, the traffic is wrapped in TLS, making it appear as legitimate encrypted outbound web traffic to most network monitoring systems.

Detection and Mitigation Strategies

Because QLNX minimizes its on-disk footprint, defenders cannot rely on traditional antivirus. Detection requires a multi-layered telemetry approach, correlating signals from syscall monitoring, File Integrity Monitoring (FIM), and network flow analysis.

Key Indicators of Compromise (IoCs) include:

• Execution of processes originating from memfd paths.
• Suspicious gcc activity compiling .so files into /tmp or /dev/fd/.
• Unauthorized modifications to /etc/ld.so.preload or PAM configuration files.
• The presence of hidden, high-entropy files in /var/log/ or /tmp/.
• Outbound TLS sessions that exhibit custom handshake patterns.

Recommended Response

Due to the depth of the eBPF rootkit and the potential for PAM-level persistence, security professionals recommend that any confirmed QLNX infection be treated as a total system compromise.

The only reliable remediation is a complete OS wipe and a reinstall from a verified, clean image. Post-incident, organizations should implement strict FIM on critical system paths and tighten monitoring of developer environments to detect the early stages of the kill chain.