Trend Micro has published the first detailed analysis of Quasar Linux (QLNX), a previously undocumented Linux remote access trojan that is engineered, end to end, to live on developer and DevOps workstations long enough to steal the credentials that publish to npm, PyPI, Docker Hub, GitHub, AWS, and Kubernetes. It is not subtle about its purpose. The credential-harvest list reads like an inventory of the files that gate every modern build pipeline.

The implant is being framed as a “silent foothold in the software supply chain,” and given how poorly it is currently detected — only a handful of engines flag the binary at the time of writing — that framing is reasonable. Operators do not need to compromise a registry directly when they can compromise the laptop with the publish token already in .npmrc.

What QLNX is

QLNX is a full-featured Linux implant: remote shell, file operations, process control, keylogging, screen and clipboard capture, persistence, and a credential harvester whose target list is unusually pointed at software supply chain artifacts. The credential paths it walks include .npmrc, .pypirc, .git-credentials, .aws/credentials, .kube/config, and .docker/config.json — the exact set of files an attacker needs to push a malicious release as you, pull from a private registry as your CI runner, deploy into your cluster, or sign in to your container registry.

The implant ships two PAM backdoor modules that it compiles on the host with gcc at runtime. The first module logs plaintext credentials from authentication events, contains a hardcoded master-password bypass, and silently captures outbound SSH session data. The second hooks dynamically linked processes and pulls service name, username, and authentication tokens out of memory. PAM is a high-trust, low-visibility seam in a Linux box, and these modules turn every successful login on the workstation into another credential drop.

The rootkit layer is two-tiered. Userspace hooking is delivered through LD_PRELOAD, which also doubles as the persistence mechanism — once a victim sources their shell, the hook is loaded into every child process. Underneath that, an eBPF rootkit controller manages kernel BPF maps to hide processes, files, and network connections from defenders running standard tooling. eBPF rootkits remain rare in the wild and notoriously difficult to detect with EDR products that themselves rely on eBPF.

Stealth and persistence are aggressive. QLNX runs in memory, deletes its dropper from disk, scrubs logs, spoofs process names, and clears forensic environment variables. It computes a DJB2 hash of the string quasar_linux and writes its lock file to a path disguised as an X11 socket lock — /tmp/.X752e2ca1-lock — so a casual ls /tmp looks unremarkable.

C2 is built for resilience. In addition to traditional command-and-control, QLNX speaks peer-to-peer mesh so compromised hosts can relay through each other when an upstream server is sinkholed. That is the same operator pattern researchers have flagged in other recent Linux malware families — operators have learned that single-server takedowns are the cheapest defensive win, and they have stopped offering that win.

Why this matters for infrastructure teams

The value of a single trojanized developer machine has gone up sharply over the last twelve months. The LiteLLM incident in March set the template: stolen credentials from one workstation were used to push a malicious release of a Python package pulling 3.4 million downloads a day. Mini Shai-Hulud last week hit Lightning, intercom-client, and SAP CAP through a similar credential-pivot pattern. QLNX is purpose-built for that economy.

If the operator successfully harvests .kube/config, the consequence is not a lost laptop — it is a hostile cluster admin in your production namespace. If they harvest .npmrc for an internal scoped package, the consequence is a tainted release shipped to every CI runner that updates dependencies overnight. The blast radius is set by your build system, not your endpoint.

What to do right now

Audit developer hosts and build runners for the QLNX lock-file pattern (/tmp/.X*-lock files that are not actually owned by an X server) and for unexpected LD_PRELOAD entries in shell init files, systemd unit Environment= directives, and /etc/ld.so.preload. Look for new PAM modules under /lib/security/ or /lib64/security/ that were not delivered by the package manager — rpm -V and dpkg -V will flag them. Hunt for unexpected eBPF programs with bpftool prog show and bpftool map show; QLNX’s controller will surface there if you know to look.

For the longer-term hardening, treat the credential files QLNX targets as crown jewels rather than convenience artifacts. Move npm and PyPI publishing to short-lived OIDC tokens via Trusted Publishers wherever the registry supports it. Push Kubernetes access through workload identity federation rather than long-lived kubeconfig files on developer laptops. Require hardware-backed signing for any package or container image that lands in production. None of this prevents the initial workstation compromise, but it shrinks what an operator can actually do once they have one.

Trend Micro’s published indicators (file hashes, hardcoded passwords, credential-harvest target paths, compilation artifacts) are the right starting point for hunting today. Pull them into your detection rules before the next package on your dependency tree turns into a Bun-based stealer wearing yesterday’s maintainer’s PGP key.

Sources