QLNX Targets Developers in Supply Chain Credential Theft Campaign

QLNX is a newly documented Linux remote access trojan (RAT) that targets the theft on developers’ and DevOps credentials to hijack software supply chains.

Recent attacks against popular projects like LiteLLM on PyPI and the Axios npm package have shown how a single compromised maintainer account can be used to push backdoored releases to millions of users.

QLNX is built precisely for this threat model: it infects developer workstations, quietly harvests the secrets that control build and publishing pipelines, and then gives attackers a persistent, stealthy foothold to weaponize those pipelines.

Trend Micro researchers describe QLNX as a full‑featured Linux implant with fileless execution, rootkit functionality, and aggressive credential harvesting tuned to modern DevOps tooling.

The malware appears to be previously undocumented and currently has low detection across traditional defenses, increasing its value for long‑term supply chain operations.

Technical Overview

QLNX runs as a 64‑bit position‑independent ELF binary that re‑executes itself from an anonymous in‑memory file created via the memfd_create syscall, deleting the original executable from disk to reduce forensic artifacts.

It checks whether it is already running from memory using indicators in /proc/self/exe and an MFDRE environment variable, ensuring it does not loop or leave duplicates.

To evade process inspection, the implant spoofs its identity as what looks like a legitimate Linux kernel thread, randomly choosing names such as “kworker/0:0”, “ksoftirqd/0”, or “rcu_sched”.

It then rewrites argv, sets the kernel thread name with prctl, and updates /proc/self/comm so common tools like ps and top consistently show the fake kernel‑style name.

QLNX also removes environment variables (like PWD and OLDPWD) that could reveal where it was launched, and enforces a single‑instance mutex using a fake X11 lock file in /tmp.

For persistence, the RAT supports at least seven mechanisms, including systemd services (user and system), cron reboot entries, SysV init scripts, XDG autostart .desktop files, .bashrc injection, and the powerful LD_PRELOAD shared‑library technique.

Each persistence artifact is tagged with the marker “QLNX_MANAGED”, allowing the malware to manage its own entries while blending into the host’s service configuration.

One of QLNX’s most dangerous traits is its use of both userland and kernel‑assisted hiding via rootkits.

At the userland level, QLNX ships embedded C source code for an LD_PRELOAD‑based rootkit that it compiles on the victim using gcc.

The resulting shared object (typically installed as /usr/lib/libsecurityutils.so.1) is loaded into every dynamically linked process via /etc/ld.so.preload, and hooks libc functions such as readdir, stat, open, and access.

These hooks selectively hide files, directories, and the malware process itself by returning “file not found” when tools probe for artifacts like the QLNX binary, the rootkit .so, or the credential‑log files.

QLNX also controls an eBPF‑based rootkit component, acting as a user‑space controller that creates and manages BPF maps to hide processes, files, and network ports from kernel‑level views.

It requires root privileges and a kernel version of at least 4.18 to use this feature, then accepts commands from the C2 server to add or remove PIDs, paths, and ports from the hidden sets.

For credential interception, the malware incorporates two Pluggable Authentication Module backdoors, again delivered as embedded C source that is compiled on the victim.

The primary PAM inline‑hook backdoor provides three functions: it harvests plaintext credentials from every authentication flow, introduces a master password (documented as “OfQtYJK”) that grants silent access, and logs outbound SSH session details for lateral movement mapping.

Captured secrets are XOR‑encrypted and stored in hidden log files under /var/log (e.g., .ICE-unix and .Test-unix), which are then hidden by the rootkit and exfiltrated on operator request.

A second, simpler PAM logger module writes plaintext credentials to temporary files and is also wired through /etc/ld.so.preload for wide coverage.

Supply Chain Compromise

Command 0x90 in QLNX’s internal protocol triggers a comprehensive credential‑harvesting routine that systematically targets assets used in modern software development and cloud deployments. In one sweep, QLNX collects:

• SSH keys (id_rsa, id_ed25519, authorized_keys, and known_hosts).
• Browser login databases and cookies from Chrome, Chromium, and Firefox.
• Cloud and container credentials, including AWS config and credentials, Kubernetes kubeconfig files, and Docker config.json.
• Developer tooling secrets such as .git-credentials and gitconfig, .npmrc (npm tokens), .pypirc (PyPI API keys), GitHub CLI tokens, HashiCorp Vault tokens, Terraform credentials, and .env files in the user’s home directory.
• System password hashes from /etc/shadow when running as root, shell histories, and the current X11 clipboard contents.

Every item is labeled with its category, source application, and file path before being exfiltrated to the command‑and‑control (C2) server over a custom TLS‑secured protocol or over HTTP/HTTPS using Base64‑encoded payloads.

On a typical developer workstation or CI helper node, this is enough to take over private Git repositories, npm and PyPI publishing tokens, and cloud production environments.

This design directly supports supply chain compromise: an attacker who deploys QLNX on a maintainer’s Linux box can silently hijack npm or PyPI accounts, publish trojanized versions of widely used packages, alter Docker images, or pivot into Kubernetes clusters used for building and deploying software.

The LiteLLM breach in March 2026, where attackers used stolen CI credentials to ship a three‑stage backdoor on PyPI.

QLNX supports three transport modes for C2 a custom TCP protocol over TLS, HTTPS, and plain HTTP, all using the same binary command framing.

Each session begins with the ASCII magic value “QLNX” sent as part of a handshake that leads into an interactive command loop.

Before connecting, the implant queries ip-api.com to resolve the victim’s geographic location, then includes country data, system profile, and a machine fingerprint derived from /etc/machine-id and MAC addresses in its initial beacon.

Once registered, the malware polls the C2 every few seconds for commands and supports at least 58 command IDs covering interactive shells, file management, process and network control, port scanning, SOCKS proxy setup, screenshot capture, keylogging, persistence management, and rootkit/PAM operations.

QLNX can also form a peer‑to‑peer mesh network, allowing compromised hosts to relay C2 traffic for each other, which makes full eradication more difficult and provides resilience if some nodes are cleaned or isolated.

Defenders should treat anomalous “kernel” processes on developer workstations, suspicious entries in /etc/ld.so.preload, and unexplained GCC usage as high‑priority indicators of compromise given QLNX’s compile‑on‑target model.

Security teams should also audit for unauthorized systemd services, XDG autostart entries, and unexpected pam modules (such as pam_security.so‑like names), especially on Linux systems used for building and publishing software.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.