A New Linux RAT Was Built to Steal npm and PyPI Tokens, and It's the Tool the Next LiteLLM Was Waiting For

Trend Micro researchers Aliakbar Zahravi and Ahmed Mohamed Ibrahim disclosed Quasar Linux RAT (QLNX) on May 4, 2026 — a previously undocumented Linux remote access trojan purpose-built to harvest developer and DevOps credentials across the software supply chain. QLNX combines six redundant persistence mechanisms, in-memory operation, kernel-level rootkit deployment, a PAM backdoor, keylogging, and credential harvesting from .npmrc, .pypirc, .git-credentials, AWS, Kubernetes, Docker, HashiCorp Vault, Terraform, GitHub CLI, and .env files. With those credentials, attackers can publish trojanized packages to npm or PyPI, inject backdoors into container images, or pivot from a personal laptop directly into production cloud environments.

On Monday, May 4, 2026, Trend Micro published the first technical analysis of Quasar Linux RAT — codenamed QLNX — describing it as a comprehensive Linux implant that combines remote access capabilities with advanced evasion, persistence, keylogging, and credential harvesting features. The malware is operationally distinct from the well-known Windows-based Quasar RAT (originally a legitimate open-source remote-administration tool that has been repeatedly weaponized); QLNX is a new, Linux-specific implant whose targeting profile and capability set are tuned for software-supply-chain operations rather than for Windows-environment espionage.

The single most operationally consequential element is the credential-harvesting target list. QLNX's harvester extracts secrets from the credential files that authenticate modern software publication and infrastructure deployment: npm registry tokens (.npmrc), PyPI upload keys (.pypirc), Git authentication (.git-credentials), AWS access keys (.aws/credentials), Kubernetes cluster authentication (.kube/config), Docker Hub credentials (.docker/config.json), HashiCorp Vault tokens (.vault-token), Terraform credentials, GitHub CLI tokens, and .env files. With those credentials in hand, an attacker can publish trojanized packages signed by the legitimate maintainer, push backdoored container images, or take over the cloud accounts the developer uses for production work.

Trend Micro's strategic framing is direct: QLNX targets the software supply chain through the developer endpoint. The company explicitly maps QLNX's capability set to the LiteLLM supply-chain compromise of March 2026, in which stolen credentials from one tool were used to trojanize a Python package with 3.4 million daily downloads. QLNX is not yet attributed to any named campaign, but its capability profile is exactly what the next LiteLLM-class incident would require.

Why the Capability Stack Is the Story

Trend Micro's framing of what makes QLNX dangerous is precise: not any single feature, but how the capabilities chain together into a coherent attack workflow. The implant arrives, erases itself from disk, persists through six redundant mechanisms, hides at both userspace and kernel level, and then harvests the credentials that matter most. Each link is, in isolation, recognizable from prior Linux malware research. The combination, and specifically the targeting profile aimed at the credential files used in modern software-publication pipelines, is what positions QLNX as a supply-chain weapon rather than a generic RAT.

The technical detail most worth understanding is the rootkit deployment path. QLNX carries embedded C source code for both a PAM (Pluggable Authentication Modules) backdoor and an LD_PRELOAD-based rootkit as string literals within its binary. On the target host, the implant uses the system's gcc compiler to build the rootkit shared object and the PAM backdoor module dynamically, then deploys the rootkit via /etc/ld.so.preload for system-wide function-call interception. That sequence (source code embedded, compiled in place, deployed via the system loader) is exactly the kind of technique that defeats signature-based detection on the binary itself, because the attack-functional shared object never existed on the attacker's distribution server. It exists only on the victim host, after the victim host has compiled it.

The Six-Mechanism Persistence Architecture

Trend Micro's official summary cites six redundant persistence mechanisms; some downstream reporting cites at least seven, including systemd unit files, crontab entries, and shell injections via .bashrc and equivalent files. The redundancy is the operational point: if a defender finds and removes one persistence anchor, the others continue running, and the implant re-establishes the missing path on the next privileged execution. This pattern is recognizable from earlier sophisticated Linux malware (Drovorub, Tycoon, Kobalos), but QLNX's emphasis on developer-targeted persistence, including shell-rc-file injection that runs every time the developer opens a terminal, is calibrated for the actual operational rhythm of a developer endpoint.

The implant also disguises itself as kernel threads such as kworker and ksoftirqd, names familiar to anyone who has run ps or top on a Linux system. Genuine kernel threads cannot be killed from userspace, which means a casual administrator inspecting the process list will see what looks like normal kernel activity and move on. QLNX's userspace process bearing a kernel-thread name is the kind of detail that requires either Linux-specific EDR coverage (Wazuh, Falco, CrowdStrike Falcon for Linux, SentinelOne for Linux) or manual hunt logic to surface, and most enterprise EDR coverage on developer endpoints does not extend that far.

The Developer Endpoint Is the New High-Value Target

Most enterprise security programs treat developer endpoints as low-risk users because their endpoints are not part of the customer-data flow. QLNX inverts that calculation. Developer endpoints hold the credentials that authenticate legitimate package publication, container registry pushes, and cloud-account access. The blast radius of one compromised developer can dwarf the blast radius of one compromised executive, because a successful publication of a trojanized npm or PyPI package by a legitimate maintainer reaches every downstream consumer of that package, while a compromised executive can typically only access the data they personally hold.

This is the same supply-chain trust problem documented in The CyberSignal's coverage of the Daemon Tools trojanized-installer campaign, where a properly signed installer shipped malware for nearly a month, the same theme of legitimate publishing pipelines turned into attacker distribution channels. The QLNX path is one step further upstream: rather than compromising packages directly, the attacker harvests the credentials that allow legitimate-looking package publication. The CyberSignal's broader application-security coverage tracks how this credential-targeting pattern has matured into a recurring 2025-2026 supply-chain dynamic.

The Adjacent SAP Mini Shai-Hulud Campaign

QLNX is not the only credential-harvesting developer-targeted operation surfacing in May 2026. On April 29, suspicious versions of SAP-related npm packages were published between 09:55 UTC and 12:14 UTC. The poisoned packages introduced a package.json preinstall hook running setup.mjs, which loaded the Bun JavaScript runtime to execute a credential-stealer named execution.js. Per Aikido research, the campaign targeted local developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud secrets from AWS, Azure, GCP, and Kubernetes. Stolen data was exfiltrated to public GitHub repositories created on the victim's own account, with the description A Mini Shai-Hulud has Appeared, more than 1,100 repositories with that description observed at time of writing.

The SAP Mini Shai-Hulud campaign and QLNX are functionally similar (both target the developer credential surface) but represent different operator toolsets and have not been linked publicly. The two together establish a pattern: developer endpoints holding npm, PyPI, AWS, Kubernetes, and GitHub credentials are now actively contested terrain. QLNX is the most comprehensive single tool publicly documented in this space; the SAP campaign demonstrates the same target list being attacked through a different delivery mechanism.

The LiteLLM Precedent and Why Trend Micro Cited It

In March 2026, the LiteLLM Python package, which provides a unified interface to multiple LLM providers, was trojanized after attackers obtained credentials from one tool and used them to publish a malicious version with 3.4 million daily downloads worth of reach. Trend Micro's QLNX writeup specifically cites that incident, noting the malware's capability set maps directly to every step of that kill chain: harvest credentials, publish trojanized package, reach downstream consumers via legitimate distribution channels. Trend Micro does not claim QLNX was used in the LiteLLM compromise. But the architectural fit is exact, and the implication is that QLNX is purpose-built to enable the next LiteLLM-class incident.

Defender Actions for the Next 30 Days

• Inventory credential files on developer workstations. Run an audit script across every developer machine to identify any of the QLNX-targeted files: .npmrc, .pypirc, .git-credentials, .aws/credentials, .kube/config, .docker/config.json, .vault-token, .env files, plus Terraform and GitHub CLI credentials. Document what credentials each file contains and who has access. The standing-credential universe is the single largest defensive lever you control this quarter.
• Migrate to short-lived, scoped credentials wherever possible. Long-lived tokens in ~/.npmrc and ~/.pypirc are the highest-value targets. Replace with OIDC-based authentication for npm and PyPI publication, short-lived AWS STS tokens, and credential-refresh workflows that minimize standing access. The cost of migration is one-time; the cost of standing-credential exposure compounds with every developer hire and tenure year.
• Implement file integrity monitoring on /etc/ld.so.preload. This file is QLNX's primary rootkit-persistence anchor. FIM alerts on any modification to this path are high-fidelity for QLNX-class detection. Pair with FIM on /etc/pam.d/ for the PAM-backdoor side, and audit systemd unit files, crontab entries, and shell-rc files for unexpected entries on developer endpoints.
• Hunt for QLNX-specific indicators. A process disguised as a kernel thread (kworker, ksoftirqd) but running in userspace is a high-fidelity signal, since genuine kernel threads cannot be killed by userspace. Watch for unexpected gcc invocations on production developer machines, particularly compiling shared objects in /tmp or /dev/shm. Watch for process injection or LD_PRELOAD-based interception flagged by Linux EDR tools (Wazuh, Falco, CrowdStrike Falcon for Linux, SentinelOne for Linux). Watch for persistent low-volume outbound connections from developer endpoints to unusual IPs.
• Brief development teams on the credential-file targeting. A 30-minute team brief covering what credentials QLNX targets, how to migrate to short-lived alternatives, and what indicators to watch for is high-impact and low-cost. Many developers do not realize that .bash_history, .zsh_history, or .bash_aliases may contain inline tokens that QLNX could harvest as a side effect; that is worth flagging explicitly.

The CyberSignal Analysis

Signal 01 - Developer endpoints are now the highest-value target in many enterprise environments

Most security programs allocate the majority of their endpoint-protection budget to executives, finance, and HR, the populations whose direct data access maps to obvious dollar-loss scenarios. QLNX is the year's clearest argument that developer endpoints deserve equivalent or higher coverage. The credentials a developer holds authenticate publication into channels with millions of downstream consumers; one compromised developer with npm publication rights can reach a customer base larger than any single executive's data access. Defender resourcing should reflect that asymmetry. Specifically: extend EDR coverage to developer Linux machines, run quarterly credential-file audits, and treat developer endpoints as a tier-1 protection class rather than a tier-3 one. The cost of doing this is meaningful but bounded; the cost of not doing it, in a year where QLNX-class tools are publicly documented and likely already in active use, is a LiteLLM-scale supply-chain incident.

Signal 02 - Package-level controls do not protect against credential-level compromise

Many organizations have invested significantly in package allow-listing, dependency pinning, and SBOM verification. Those controls remain valuable but do not protect against the QLNX scenario. If an attacker has stolen a legitimate maintainer's npm credentials, the resulting malicious package is signed by the legitimate publisher, ships from the legitimate registry, and passes most allow-listing rules. The defensive architecture has to combine package-level controls with credential-level controls: short-lived tokens, OIDC-based authentication, MFA-protected publication, and detection for credential abuse on the publisher side. Dependency-pinning organizations should specifically reassess whether their pinning strategy assumes maintainer-credential integrity, because that assumption is now empirically weakened.

Signal 03 - Linux EDR coverage on developer endpoints is the unfunded liability of 2026

Enterprise EDR coverage in 2026 is mature for Windows and reasonably mature for macOS. Linux coverage on developer workstations is, in most enterprises, comparatively thin: the developer's machine runs whatever distribution they prefer, with whatever tooling they install, behind whatever VPN configuration they have. QLNX exploits exactly that gap. The fix is not glamorous and not free: extend a Linux EDR product to developer machines, accept the friction of agent installation, and update incident-response runbooks to include Linux-specific telemetry. The unit cost is small relative to the supply-chain blast radius being protected. Organizations whose CFOs have deferred Linux-EDR coverage on cost grounds should treat the QLNX disclosure as the trigger for revisiting that decision.

Sources