Unmasking QLNX: The Stealthy Linux RAT Targeting the Software Supply Chain

In the evolving landscape of cyber threats, the most dangerous attackers aren’t just looking for data—they are looking for influence. A newly documented Linux Remote Access Trojan (RAT), dubbed QLNX, is purpose-built for this exact mission: hijacking the software supply chain by compromising the very people who build it.

We have already seen the devastating potential of “account takeover” attacks, such as the recent compromises involving the LiteLLM project on PyPI and the Axios npm package. These incidents demonstrated how a single compromised maintainer can push malicious code to millions of downstream users. QLNX weaponizes this reality by targeting developer workstations and DevOps environments to harvest the high-value secrets that control modern CI/CD pipelines.

According to researchers at Trend Micro, QLNX is a sophisticated, full-featured Linux implant. It utilizes fileless execution, advanced rootkit capabilities, and highly specialized credential harvesting to remain undetected by traditional security perimeters.

Deep Dive: Technical Architecture and Evasion

QLNX is engineered to leave as little forensic evidence as possible. It operates as a 64-bit position-independent ELF binary. Upon execution, it employs the memfd_create system call to create an anonymous file in memory, re-executing itself from this space before deleting the original on-disk binary. This “fileless” approach makes it significantly harder for traditional antivirus tools to flag the malicious process.

To maintain a low profile, the malware utilizes several sophisticated deception techniques:

• Process Spoofing: To evade inspection via ps or top, QLNX masquerades as a legitimate Linux kernel thread. It randomly adopts names like kworker/0:0, ksoftirqd/0, or rcu_sched by rewriting its argv and using the prctl system call.
• Environment Scrubbing: It strips sensitive environment variables like PWD and OLDPWD to hide its launch context and uses a fake X11 lock file in /tmp to ensure only one instance runs at a time.
• Extensive Persistence: QLNX offers a “choose your own adventure” of persistence. It can embed itself through systemd services, cron jobs, SysV init scripts, XDG autostart files, .bashrc injections, and the highly effective LD_PRELOAD technique. Every artifact it creates is tagged with QLNX_MANAGED, allowing the malware to track and manage its own presence.

Perhaps most alarming is its dual-layer approach to concealment: Userland and Kernel-level hiding.

At the userland level, QLNX uses a “compile-on-target” strategy. It carries embedded C source code for an LD_PRELOAD-based rootkit, which it compiles locally using gcc. Once installed (often as /usr/lib/libsecurityutils.so.1), it hooks fundamental libc functions like readdir, stat, and open. If a sysadmin tries to look for the malware’s files or processes, the rootkit simply tells the OS that those files “do not exist.”

For even deeper invisibility, QLNX utilizes eBPF-based rootkits. On kernels version 4.18 or higher, it acts as a user-space controller for BPF maps, allowing it to hide processes, files, and network ports directly from the kernel’s view. This level of stealth makes the malware virtually invisible to standard system monitoring tools.

The Payload: Weaponized Credential Theft

The true intent of QLNX is revealed through its internal command protocol. When the 0x90 command is issued, the malware begins a systematic vacuuming of the developer’s digital identity. It specifically hunts for:

• Identity & Access: SSH keys (id_rsa, id_ed25519), authorized_keys, and system password hashes from /etc/shadow.
• Cloud & Infrastructure: AWS configuration files, Kubernetes kubeconfig, Docker config.json, and HashiCorp Vault tokens.
• Development Ecosystems: .npmrc (npm tokens), .pypirc (PyPI keys), .git-credentials, and GitHub CLI tokens.
• Session Data: Browser cookies/databases (Chrome, Firefox), shell histories, and even the current X11 clipboard contents.

To intercept real-time logins, QLNX deploys Pluggable Authentication Module (PAM) backdoors. These backdoors can capture plaintext credentials from every authentication attempt and even include a “master password” (notably OfQtYJK) that allows the attacker to bypass security entirely. Captured secrets are XOR-encrypted and stashed in hidden logs in /var/log, such as .ICE-unix, before being exfiltrated.

C2 Communication and Resiliency

QLNX communicates with its Command-and-Control (C2) servers using a custom TLS-secured protocol, though it can fallback to standard HTTP/HTTPS. Every session is marked by an ASCII handshake containing the magic value "QLNX".

Before the first connection, the implant performs “reconnaissance-by-proxy,” querying ip-api.com to determine the victim’s location. It then sends a beacon containing a detailed machine fingerprint, including the /etc/machine-id and MAC addresses. Once established, the attacker has a massive toolkit—over 58 different command IDs covering everything from SOCKS proxies and keylogging to screenshot capture and P2P mesh networking.

The P2P mesh capability is particularly dangerous; it allows compromised hosts to act as relays for one another. This creates a resilient web of infection, meaning that even if one machine is cleaned, the attacker may still maintain access to the network through another “node.”

Defense and Detection Strategies

Detecting QLNX requires moving beyond simple signature-based scanning. Security teams should prioritize the following indicators of compromise (IoCs):

• Anomalous Kernel Processes: Investigate any “kernel-style” processes (e.g., kworker) that appear on developer workstations or CI/CD build nodes.
• Suspicious Compilation Activity: Monitor for unexpected usage of gcc or other compilers on production or developer machines, as QLNX compiles its rootkits locally.
• File System Integrity: Audit /etc/ld.so.preload for unauthorized shared libraries and inspect /var/log for hidden files (e.g., .ICE-unix).
• PAM Auditing: Regularly check for unauthorized or newly added PAM modules, particularly those with names resembling legitimate security utilities.
• Service Monitoring: Watch for unauthorized systemd services or XDG autostart entries that carry the QLNX_MANAGED marker.